• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    A method and systems for managing and sharing medical patient data in the context of a case that is a finite sequence of events produced by the responders to that patient. The method organizes the data into information objects (113, 123, 1113, 1123), defines the case (103) and makes available to the speakers a software workspace (102, 108, 3) by which they can operate on information objects by using predefined operational procedures if stakeholders are authorized by authorization procedures. The systems allow the transmission and the sharing of information to carry out the method of the invention.
    公开号:CH712507A2
    申请号:CH00649/17
    申请日:2017-05-17
    公开日:2017-11-30
    发明作者:Sandoz Alain
    申请人:Vaubantechnologies Sàrl；
    IPC主号:
    专利说明:

    TECHNICAL FIELD [0001] The invention relates to the transmission of information, and more particularly to the problem of sharing information between different parties having different rights and needs in relation to the data transmitted. The present invention applies in particular to the field of medicine in the context of a medical case, that is to say in the treatment and in all the tasks necessary to meet the need of a patient who requires medical assistance .
    Prior Art The complexity of medical treatments makes the task of managing access to data particularly difficult and difficult. This is not the only area in which we have to deal with this problem. The same difficulties are also present in the management of legal or judicial procedures, for example. To simplify the description, this document will deal only with the case of the management of reserved medical information, but it should be understood that the present invention also includes the other technical fields in which it is applicable.
    In the context of medicine, any information related to the patient is legally subject to data protection constraints, including access control, very restrictive. These constraints restrict in practice the exchange of information between practitioners or other stakeholders in the care of the patient Consequently, these exchanges must be done, most often, by technical means of exchange of nature "point to point ", such as e-mail, fax, postal mail, telephone, or the transfer of physical information such as X-rays or electronic data carriers containing medical imaging results or laboratory analyzes.
    In this form, the point-to-point exchange of data is accompanied by an implicit or explicit transfer of responsibility between professionals in relation to this information. This leads to delays, loss of data or difficulties in locating data, poor traceability of exchanges, and in general, a reluctance to practice the exchange of data between practitioners. Moreover, this excludes most of the time the patient from the information exchange circuit on which he is generally informed in a lacunary and unclear way.
    In the prior art are known multiple computer systems for managing medical information, whether in hospitals or in the outpatient practice of medicine. These systems are designated for example under the name of "electronic patient record" or DPE. A given system typically groups medical information about a given patient into a central logical location called the patient's "record." The patient's file thus becomes the unit for managing and sharing information. The various stakeholders in the treatment of a patient have either access to the entire file or no access to this file. In this case, they may have access to their own file version for this patient on another computer, this version not being in general a copy, but a set of other contents.
    This approach, however, suffers in its current implementations of significant deficiencies, in particular on the one hand concerning the control and traceability of the exchange of information and the impossibility for the patient to have access thereto, and on the other hand part of the lack of interoperability between the different programs or IT systems of the different practitioners involved.
    Another limitation of this prior art is that the duration, scope and granularity of the sharing of information concerning a patient can not be regulated in a fine and independent manner from one speaker to another.
    [0008] In the prior art, multiple data standards are also known in medicine, pharmacy, medical imaging, laboratory analyzes, pricing and billing of services, etc. Each computer system must choose for the objects it manages, elements among these standards that will allow interoperability with other systems that use the same standards. Moreover, most of these standards are not open standards, but works protected by copyright or licenses.
    The invention in question here does not question this situation and does not propose a new standard for data exchange, but relies, as far as the interoperability of the systems, on the standards employed by these systems.
    BRIEF SUMMARY OF THE INVENTION [0010] The invention proposes a mechanism that makes it possible to solve the problem of sharing information between stakeholders of the treatment of a patient in a distributed medical information system.
    In the invention, this goal is achieved by a set of technical resources for managing the sharing of information objects of a case 103 in accordance with both the legal constraints on the confidentiality of data and the needs of stakeholders whose primary mission is to restore or maintain the health of the patient. In this context, preventing or delaying access by an intervener to information 113, 123 can have very serious consequences.
    The invention aims to overcome the deficiencies of the current methods of sharing medical information either from the point of view of data protection or from the point of view of the access point to the data needed for optimal processing of the patient [0013] The invention in question here is intended to solve the problems of known systems. It is a system whose effect is to 1) allow the participants in a case 103 to exchange medical information; 2) to involve the patient in these exchanges; 3) complete and accurate control and trace these exchanges at the level of granularity of the data or medical document exchanged 1113, 1123; 4) ensure, through a network of speakers and computers operating asynchronously, the logical and temporal consistency of the information exchanged; And (5) to some extent allow the interoperability of the underlying information systems 6, 7, 8,106, 13, 14, 15, 16, etc., to be shared with the data exchanged by stakeholders.
    The invention defines the "case" as being the central place for the sharing of information and control of this sharing. In this context, the invention enables the patient to play a direct role in the management and sharing of medical information concerning him, and in particular the invention provides him with the possibility of introducing into the system information derived from his personal monitoring such as, for example, a cardio-frequency-meter or any other device of this nature.
    BRIEF DESCRIPTION OF THE FIGURES [0015] The appended figure schematically illustrates a communication and data management system according to the invention.
    The central components are the case management system 1; the electronic patient record 2 internal; the service invoking subsystem 102,108, as well as the patient and family, 3 allowing them access to the case management system and other services if permitted; the peripheral clinical system 4; the internet cache 5 by which the information objects (113, 123) are made persistent.
    These central components include services such as dispatching services 24, calendar 25, or internal logistics management 26 for the clinical information system 4; billing services 21, laboratory prescription management 20 or pharmacy 23, or medical imaging management services 22. These services are invoked by information objects during the execution by the stakeholders of the methods of these objects.
    The case management system 1 can define for a patient a case 103 with which stakeholders can interact from their DPE 102,108; in which the objects 113,123 may be shared, modified or invoked in a form 1113,1123 specific to the case; and with which stakeholders will be able to interact with external services such as Compendium 13, Medication Planning Service 14, Expert Systems 15,16, Imaging Services 106 or Laboratory 6, or even external DPEs 7 , 8.
    The security of the communication of these internal or external services is based on the secure internet interfaces of the system 11. The external services such as 6, 7, 106 can be integrated into a federation of services 19 and communicate securely to the network. using a standardized and secure point-to-point transport platform 12. The interaction with certain services 8 is done using specifically dedicated connectors 18. That of other services 13, 14, 16 is done using internal web services 17 allowing not only security, but also the qualification or billing of these external services when needed.
    Finally, other clinical services 9 can interact with the case management system 1, particularly in the very strict framework defined by the law of 19 June 2015 on the electronic patient record (LDEP), its prescriptions for application and their technical annexes, defining inter alia the notions of community and integration profile and specifying services 31 for the exchange of data between systems.
    EXAMPLE OF EMBODIMENT OF THE INVENTION The invention consists on the one hand of a specific "core" which is the technical component making it possible to achieve the consistency of data exchanges in a distributed, heterogeneous and multi-dimensional context. -agents, and secondly the implementation in this nucleus of a "mechanism" allowing the sharing of medical information units called "information objects".
    In accordance with the principles of object-oriented software design, an "object" consists of a "data" part and a "methods" part. In the context of the present invention, the data of an object are generally defined by a standard of structured data from the field of application in question (medicine, pharmacy, medical imaging, laboratories, pricing and billing of services, etc.). ; the methods may vary depending on the type of object, but the allocation through the mechanism of sharing the permission to execute either method by the recipient of the shared object allows the control sharing according to specific constraints defined and defined by the issuer.
    The invention relates to a mechanism for sharing between stakeholders, health professionals or others, medical or other information about a patient, for an indefinite period of time but finite, in a specific context designated by the term "case" 103.
    The business context in which these sharing operations are implemented is that of the "case". A case is a sequence of events concerning a single patient, which has a beginning and an end, and represents a set of tasks performed by medical personnel or other persons involved, including the patient himself or his representatives , in order to treat a health problem of that given patient.
    The "case" as defined in the context of this invention is a new object of control of medical information. Its software-based management provides stakeholders with technical capabilities (eg, transmission and visualization of medical images) for sharing and protecting medical information about their patient. The core, in particular, implements the competition control of access to each case by authorized stakeholders.
    For a case at a given time, all stakeholders may include one or more health professionals. This list may vary over time. The set of information objects paid to the case may include objects shared between several stakeholders, or data remaining confidential and accessible to a single speaker. This set too can vary over time.
    As indicated above, the case is a sequence of events taking place in a specific context, in particular with a single patient; a beginning, following which the case is open; a variable set, but never empty of speakers; objects paid to the case by stakeholders who are, at any given moment, accessible by sharing to some of them and not to others; finally an end which is the event that closes the case.
    The events that define a case may be of different natures and are not a priori limited in the variety of their kind. Some of these events relate to the sharing of information. These are, in particular, intervener actions in the event of achieving: - the fact of paying an information object to the case; - Inviting a new stakeholder to participate in the case; inviting an active stakeholder to become aware of information provided in the case; - inviting several active stakeholders in the case to take note of information provided in the case; - the fact, for an intervener, to refuse to take cognizance of shared information in case; the fact that an intervenor withdraws from the list of interveners in the case; etc.
    The definition of the "case" as being the context in which the sharing of information is managed provides an original organizational framework which makes it possible to develop new ways of controlling access and the dissemination of information over time, in scope and granularity and this consistently and complies with legal constraints.
    The invention relates to the technical mechanisms for implementing the case management, and in this context, the management and sharing of information relating to the patient who is the subject of a given case.
    The invention comprises in particular a computer system built and arranged to provide various stakeholders a platform to manage the following questions, among others: - which is the owner (at a given moment) of an object d ' given information - as an object can exist before being paid to a case and persist after the case is closed, is the property of the object a feature independent of the case concept - when an object 1113, 1123 is shared by several stakeholders in a case, can each stakeholder modify the object share it in turn with another speaker hitherto not concerned by the object to delete it - are there other possible operations on an object than sharing, editing, deleting - if yes, are these operations the same for all objects - Do all stakeholders have the same rights to perform operations on an object they share - What are the rights of a patient on an object that concerns him are these rights limited to the context of a case or do they have a scope that goes beyond all cases (open or not) concerning it - can a patient himself give an object in one of the cases that concern him Can he forbid an active participant in a case to have access to an object paid in the case - etc.
    The system of the invention makes it possible to treat these problems either automatically or by actions of the speakers.
    In addition, certain events in the sequence of events of a case do not relate directly to the management of information objects, but may give rise to the creation of new objects. For example: in the ambulatory field, a consultation (which can be an event in the context of a case) includes a list of services that gives rise to an invoice according to the medical tariff applied. This list is an information object that (as an object) may have a method for generating an invoice. The data of such an object must be able to be corrected; it must be accessible to non-medical administrative staff; it must not be accessible to the patient before the invoice is ready for dispatch; it can not be copied; once the invoice has been dispatched, it can not be modified or destroyed; it must not be shared; etc.
    In the case of a hospital act (for example a block operation), the event will give rise to a very complex coding of the operation. There are several medical professionals (block nurses, technical staff, possibly the anesthesiologist, for example) who will never be "stakeholders" in the "case" as these concepts are defined and used here. What is the class of an object produced by this event In the case of the call to an external expertise service (for example, a decision support system 14 to establish a medication plan for this patient or a complex prescription), access and the use of the result of this operation may depend on the prior payment of the service 17, 21.
    [0036] Etc.
    Many questions arise as to the implementation of the concept of shared object in the context of a patient's case.
    The invention defines the basic technical elements that will allow programmers of a system to implement in a safe and consistent manner the answers to these questions that will be chosen by a software manufacturer. These elements are as follows: [0039] Γ "information object" 113,123 is an entity that can be shared between the speakers of a case. It includes a "data" part generally defined according to a standard of the field of application (medical or other) and which can be transmitted over a network using Internet technologies, including XML technologies and web services. It also includes a "methods" part that defines a set of operations that can be performed on this object in the context of sharing and on the computers that implement these operations. These are operations such as reading, copying, sharing or modifying, for example, or even other services specific to the object that could be invoked on this datum. By way of example, an object comprising in its given part a medication plan can provide in its methods part functions making it possible to produce an order expressing part of this plan and to transmit it to a pharmacy, with the effect, besides the transmission to this pharmacy, to prevent transmission to a second pharmacy.
    Each active stakeholder in a case, who has access to a shared object paid to the case, is allowed or not to execute the methods of the object. The speaker therefore has access to an "object descriptor" which contains in particular a reference on the object and a mask (implemented for example, but not restrictively using a bit-set) which defines the stakeholder's own performing rights on the methods of the object.
    The "kernel" is a software component (which can be centralized on a computer or distributed on several computers connected by a network or the Internet) which includes all the primitives for managing in a consistent and consistent manner: - each individual case , including the events that compose it as its beginning, its end, the arrival or departure of speakers of the case, the deposit of objects in the case and the sharing of these objects
    - shared information objects (OIP) and in particular for each stakeholder the OIP descriptors - the invocation of information object methods or the invocation of services to which the object can be passed as an argument - the traceability of Sensitive Operations Related to Information Sharing [0042] The kernel also includes an "information object sharing" primitive whose function is to implement atomically and consistently the system state changes relating to the information exchange. access to information objects, particularly to IOPs.
    In the attached figure, the patient is represented by a character with a bandage on the forehead. The responsible treating physician (MTR) is represented by a person dressed in white. The last character ("surgeon") is an attending physician (MTI) in the case.
    The appended figure represents the various internal components of the system that are involved in the patient's treatment process (in the case management concept 103), or external components that interact with this process: [0045] The management system Case Management System (CMS) 1 makes it possible to trace and make visible to those who have the right, the operations performed in order to treat the medical situation of the patient. It comprises a sequence of events, each representing a group logically related operations and extends between a case opening stamp (to) and a terminal stamp (tend) [0046] The case management system 1 s interface with a secure web layer 11 which makes available to stakeholders a set of web interfaces and / or web applications allowing the stakeholders to operate on the information objects through a collection of predefined procedures, verifying that they are allowed. The web communication layer preferably integrates a user identification system by single sign-on (SSO, SAML 2), and user managed access (OAuth 2.0, LIMA), etc.
    The medical information system (SIM) of the invention preferably comprises an electronic patient records management module 2 which collects all the medically significant operations performed by a professional for a patient. In the example shown, the MTR 102 and an MT1108 can for example log information objects in case 103 from their electronic files and, conversely, download case information items in their electronic files (7 for the MTR and 8). for the MTI).
    The patient also has access to the medical case concerning a web application 3 provided for this purpose. A central feature of the invention is that the MTR or the owner of the different information objects paid to the case in 1 can determine, by the defined procedures, the rules of access to the individual information objects, including their accesses by the patient.
    Another important aspect of the invention is the possibility of performing a continuous multi-parameter and accurate monitoring of the state of health of a patient and to follow the evolution of his clinical parameters without the patient having to to consult. To this end, the system of the invention is preferably arranged to collect data from diagnostic devices, and present them to stakeholders as a timeline. These diagnostic data can come from laboratories or medical imaging centers 6,106, but also from devices physically carried by the patient, for example heart rate and blood pressure sensors, implanted diagnostic devices, sensors connected to devices training and rehabilitation, and so on.
    Preferably the system of the invention is also open to external medical file management systems, such as for example unit 4 which represents a management application of a group practice or a clinic employing the medical device system. medical information to manage the case and share information about it between stakeholders.
    The system of the invention can preferably cooperate with external patient data management systems ("legacy") such as unit 7 which is an electronic patient record external to the SIM in which the MTR has an account and a input for the patient in question, and who can communicate with the SIM via the secure transport layer 12 with the appropriate adapters for the SIM (for example the secure communication system SEDEX in Switzerland). Unit 8 is an electronic patient record external to the SIM in which the MTI has an account and an entry for the patient in question, but who can not communicate with the SIM via the secure transport layer 12, and for which an ad hoc data transfer service 18 has been implemented and deployed.
    An Internet cache 5 allows the storage and securing of active data or having been active in the SIM 113,123, and synchronize these data with the data from the external systems 7.
    In addition to the laboratories 6 and the imaging centers 106, the peripheral data service systems may also include the pharmacy, etc.
    Unit 9 represents the management application of a group practice or a clinic (just like 4). Several such systems, which are organizational or administrative autonomous, can be connected in parallel to the CMS and the SIM, in particular because the same treating physicians and the same patients can be managed by several different private or public organizations at the same time. .
    The system can also cooperate with external expert services 13, 14, 15, 16, decision support services, groups of medical specialists, etc. to which requests may be made concerning a case 103.
    PREFERENTIAL EMBODIMENTS OF THE INVENTION The preferred embodiment of the invention is that of a distributed medical information system (SIM), built according to the rules and with the open standards of the Internet, in particular for security (for example, but not restrictively with standards like SAML 2 or OAuth 2.0 / UMA), or for secure point-to-point transport of structured data (with secure public platforms such as SEDEX in Switzerland).
    The system architecture of this embodiment is divided into five components interfaces between them, and accessed by users or services, directly or indirectly through the Internet. COMPONENT I: Case Management Subsystem 1 [0058] The case management subsystem (called the CMS for Case Management System) manages a list of cases that can, at a given moment, be opened or closed.
    A case is a discrete sequence of events, totally ordered by the flow of natural time or a compatible internal time of the system. The CMS defines (exposes or exports) a set of events (event classes) that can be triggered in one case atomically.
    Each case relates to a single patient who is referenced in the central patient register (MPI for Master Patient Index). At any time, a patient may have zero, one or more open cases and zero, one or more cases that have been closed. At some point, each case has a single responsible treating physician (MTR) who oversees the execution of the case. The MTR may change during the course of the case. The MTR change is a technically delicate operation that requires synchronization through the kernel mechanisms. The mechanisms in question are, however, conventional. A case may have several treating physicians intervening in the case (M7T), which must be the MTR. All MTIs are referenced as physicians in a central user register (MUI). Each MTI must have a personal account in the SIM which gives it access to a personal domain protected by the DPE. The patient of a case in which an MTI is involved is defined as a patient of that physician in his or her nominal area of DPE. It is logically by the DPE of the MTI and under the civil and penal responsibility of this MTI that all the information that this doctor will consult, create, exchange, modify, etc. in the course of his treatment of this patient's case.
    The CMS maintains all the cases of the system (the set of all instances of objects of a class "case") and it manages in particular: - the possibility at any time to access all the cases, open or closed, by the actors having rights of access on these cases - the sharing of these objects among the speakers - the traceability and the historization of the events in relation with the speakers - the notification of the events to the users of the CMS who participate in the case (eg the patient himself) depending on the type of event and the notification rules specific to each stakeholder and each type of event.
    An authorized practitioner (doctor registered with the MUI, administrative employee, nurse), can at any time open a new case in the CMS and connect to a patient. This may require the user to create in the MPI a new entry for this patient (which is a kernel-controlled operation). In all cases, the first two events following the opening of the case are 1) an invitation to a treating physician to be the MTR and 2) that physician's response to this request (acceptance or refusal). If the doctor accepts the invitation, and only in this case, then the case can start operationally. If the doctor refuses the invitation, then a new invitation must be issued to find another MTR. COMPONENT II; information object management subsystem of the attending physician, namely the DPE or electronic patient record 2.
    The primary function of a DPE is to encode the medical information in an electronic format and in a form that allows its processing and its restitution. This information is coded in the form of structured data, this structure being generally defined in a standard.
    The object management subsystem of the SIM is designed to enable the creation, use and transmission (through sharing) of medical information objects concerning a patient under the responsibility of a physician. dealing nominally with an authorized DPE user account.
    To any object in the system is associated a class that defines its data part (possibly according to a standard of the field of medicine, with a structure encoded in XML) and its associated methods part.
    Any information object defines basic methods that are for example, but not exclusively: - the method of sharing the object (in the context of a specific case) that allows to define for each speaker in the case of the execution rights of this stakeholder on the methods (and thus the operations on the data) of this object. The sharing method uses the notification service, in particular to request individual recipients of a share an acknowledgment. The recipient may refuse the sharing, in which case the rights he previously had on the subject if there were any will not be changed. the copying method of the information object that implements a duplicate of the data, this duplicate becoming the property of the intervener invoking this method. the method of modifying the data of the object, the implementation of which depends on the underlying structure of the object (by overloading a basic method of the empty object which is, for example, an editor of the object; text). - the method of deleting the object, the object being in fact never deleted, but only archived with its history and therefore only accessible in very special circumstances through low-level protected primitives. - the method of visualization of the data. - the method of printing the data. -Etc.
    An information object can be passed as a parameter to a service. If this service is internal, the entire object can be passed as a parameter, ie data and methods. Therefore, the method execution check must apply to the service in question. If this service is external, it is the data of the object that must be passed as parameter; unless the whole object (data and methods) is implemented on the said external system.
    The result of the execution of a service to which an object has been passed as a parameter may be a new object which must be managed accordingly.
    A speaker who receives an object in sharing in a case actually receives only a reference on this object (the data are not copied during the sharing). This reference remains active in the DPE of this speaker if he is a doctor as long as the case is open and he himself remains involved. As the patient has become patient with this treating physician, the reference on the subject remains present, but inactive, in his DPE after the case has been closed or the doctor has left the case.
    What must or can be done with this reference by the MTI is defined by the manufacturer of the system according to the needs of doctors and the legislator.
    Copying an information object may be necessary or useful as part of the general medical treatment of a patient. For example, the patient may request that a copy of an item be sent to a physician who is not an intervenor in an open case concerning that patient. Or, a doctor who becomes a treating physician responsible for a case may require that all the objects shared in the case be provided to him in the form of a copy (he therefore becomes the owner of the copies and may share them as he sees fit under his own responsibility. ). An object can also be copied by an intervener to be transmitted to its own external DPE. To avoid a systematic or excessive copy of the shared data, the copy operation may, for example, be billed separately to the MTI. COMPONENT III: the core, OIP descriptor management and access control subsystem of information object methods. The kernel is here a set of primitives as it is the case of an operating system in the computer field. The kernel is therefore underlying all the functional components of the system.
    Its role is to provide the data structures and primitives that consistently manage all the information of the medical information system, and this regardless of the concurrent access of multiple users or the distribution of data. components across the network, and as a result of their asynchronous behavior. The kernel implements invariants and predicates.
    For example, the number of owners of a given object or the number of MTRs of a given case is always equal to 1.
    Or, all the treating physicians intervening in a case have at every moment the same logical and causal view on the data, even if for some this view can be partial. COMPONENT IV: the Service Invocation Subsystem; entry point of the web application for users, speakers 102,108 and patients 3; user context manager.
    [0075] Any user accesses the system via this component. Access authorization is done according to a "single sign-on" (SSO) policy implemented for example, but not exclusively, according to the SAML 2 open standard. The SSO approach makes it possible to identify this user on any active component of the system accessible through the access control services of the domain in question and automatically authenticate it on the basis of a single operation of connection, identification and secure authentication.
    The services may be services internal to the SIM, for example, but not exclusively, a central register of the speakers (MUI for Master User Index), a central patient register (MPI for Master Patient Index), a service of outpatient billing, a coding service for non-ambulatory hospital procedures, the case management service, or the personal care management service of the attending physician (own and registered DPE of the attending physician in the SIM). They may be external services, such as, but not limited to, a Compendium Medication Service, a Clinical Decision Support System, an Expert System, an Image Viewing Service or Laboratory Results, etc. .
    For a particular patient, this component provides services enabling him to access information objects concerning him in the cases, open or closed, in which he is or has been treated, and this in accordance with the rights which will have been conferred by the MTR of the case. The component also allows him to transmit to stakeholders open cases concerning him information objects relating to his state of health: messages, but also data provided by devices for measuring the pulse, pressure, temperature, weight, sugar level, or any other physiological or behavioral parameter that can be measured or described by an external system.
    COMPONENT V: Internet cache subsystem 5 for structured data management and interfacing with peripheral systems (imaging, laboratories, other DPEs, hospital systems, etc.) through a secure platform 12 of transport of structured information (eg SEDEX in Switzerland). The subsystem is responsible for maintaining for each information object in its cache a counter of references on this object visible from the DPE of the various stakeholders.
    Table of Components Numbered in Figures [0079] 1 Case Management System (CMS) 2 Internal Electronic Patient Record 3 Patient Access Web Application 4 Integrated Clinic 5 System Persistent Object Web Cache 6 Laboratory Management System 7 External DPE integrated by web service 8 External DPE interface with connector 9 Clinics or external group practices 10 Services in the open internet domain 11 Secure web interface of the system 12 Secure communication platform 13 Compendium external service 14 External drug planning service 15 Non-integrated external expert service 16 Integrated external expert service 17 Internal integration service 18 External data transfer service 20 Laboratory prescription management 21 Billing service 22 Medical imaging management service 23 Pharmacy prescription management 24 Dispatch Service 25 Calendar Service 26 Service internal clinical logistics management
    31 LDEP-based exchange service 102 Context of the physician in charge 103 Specific case considered at a given moment 106 External imaging treatment system 108 Context of the physician involved 113 Persistent information object in the cache
    权利要求:
    Claims (29)
    [1]
    123 Object of persistent information in the cache 1113 Incarnation in the case of an information object 1123 Incarnation in the case of an information object Table of abbreviations [0080] CMS Case Management System DPE Electronic patient record OIP Object d Information Shared MTT Physician Dealer Intervener MTR Physician Handling MPI Manager Master Patient Index MUI Master User Index SIM Medical Information System SSO Single Sign-On Claims
    A method of transmitting and sharing information for managing access to data as part of a medical treatment by a plurality of stakeholders, comprising the technical means for: organizing the data into information objects (113, 123 , 1113, 1123), each information object associating information and operational procedures for using the information, arranged to allow or deny access to the information according to predefined authorization rules, define a case (103), either a set of software means representing operations executed in order to treat a medical situation of a given patient, providing a software workspace (102, 108, 3) to intervene by which they can operate on the information objects by a collection of predefined operational procedures, provided that they are authorized by the authorization procedures.
    [2]
    2. Method according to the preceding claim, wherein said case comprises a sequence of events, each event representing a logically connected group of operations or tasks.
    [3]
    3. Method according to one of the preceding claims wherein said operational procedures include, inter alia: creating, modifying or destroying an event; create, destroy or modify an information object; to provide an information object to a case; invite a new stakeholder to participate in a case; inform one or more stakeholders of information provided to a case; define and / or modify the authorization rules for an information object; invoking external services on an information object; copy an object into or from a medical record management system (7, 8); view or print an object; specific processing operations and related to the nature of the data contained in the object; remove an information object from a case.
    [4]
    4. Method according to one of the preceding claims wherein the information objects are composed of a data part and a method part, a method defining an executable operation on the data of this object.
    [5]
    5. Method according to one of the preceding claims comprising the attribution of the property of an object to an intervener in which a second party can access the object which he does not own by a reference recorded in a system of second responder file management.
    [6]
    6. Method according to one of the preceding claims, wherein the stakeholders interact with the workspace by secure connections (11,19), and the information is transported by secure transport mechanisms (12).
    [7]
    7. Method according to one of the preceding claims, wherein the operational procedures are atomic.
    [8]
    A transmission system and information sharing for the management of data access as part of a medical treatment by a plurality of stakeholders including a plurality of computing and storage hardware resources programmed to perform the method of the one of the preceding claims.
    [9]
    The system of claim 8, comprising a cache unit operably arranged to maintain a consistent representation of the data (113, 123).
    [10]
    10. System according to one of claims 8 to 9, comprising a web server operatively arranged to serve users a web application (3, 102, 108) allowing them to act in such a workspace.
    [11]
    A computer program comprising instructions for programming a computer or a plurality of computers to carry out the method of one of claims 1 to 7.
    [12]
    12. A medical information system on the internet that allows the sharing of medical data of a patient between the parties involved in the treatment of this patient in accordance with the treatment needs and the legal constraints of confidentiality, the system being characterized by a set of software mechanisms (in the sense of the operating systems) allowing to carry out the management of the interventions, in a consistent and totally ordered way with respect to the logical perception of the time of the speakers, these mechanisms being implemented in a centralized or distributed core, and consisting of data and primitive structures for a) implementing a shared business context called "case" (103) for sharing data between stakeholders b) implementing a personal business context of the stakeholder, called "electronic patient record" (2) , allowing in particular, but not exclusively, the creativity and the use of data by the attending physician under its nominal responsibility c) implement a container called "information object" (1113, 1123) for the control, and especially the differentiated authorization, of the execution of operations on structured medical data d) implementing a workspace for the speaker (102, 108) in which the latter can operate in a choice in one or the other context, and perform operations on information objects , create events, share objects and invoke external services on these objects e) implement an Internet cache (5), consistent logically permanently (ie virtually synchronous between stakeholders), in which the data (113,123) can be maintained consistently between the present medical information system (1, 2, 5) and other peripheral systems (7) connected to said system through different components and technical layers for the transport of data and the security of trade.
    [13]
    The medical information system according to the preceding claim wherein the "case" context (103) is implemented as a sequence of events that represents a set of tasks performed by medical personnel or other persons involved, including the patient himself or his representatives, in order to treat a health problem of this particular patient, such a sequence of events taking place in a specific medical context, in particular with a single patient; a start event, following which the case is open; a variable set, but never empty of speakers; objects (1113,1123) paid to the case by the interveners who are, at any moment, accessible by sharing to some of them and not to others; and an ending event which is the event that closes the case.
    [14]
    Medical information system according to the preceding claims, in which the context of an electronic patient record of an intervening physician (102, 108) in the case (103) is implemented as an information object management system. , the set of information objects forming a partition into disjoint subsets, each subset being associated in a bijective manner with a single person who is defined as a patient of the attending physician.
    [15]
    Medical information system according to the preceding claims, in which the objects (113, 123) are composed of a part of data and a part of methods, a method in the sense mentioned above being an operation that a computer on which the system or part of the system is implemented, can execute on the data of this object.
    [16]
    16. A medical information system according to the preceding claims, in which the sharing of the medical data is defined by the methods that an active participant in a case is authorized to execute on data, these data and methods being those defined by an object. information provided in the case.
    [17]
    17. Medical information system according to the preceding claims, in which the property of the data of an object, and thereby the property of the object itself, can be attributed to an intervener of a case (103). so that the sharing of the object (1113, 1123) with another stakeholder only relates to the availability or not of a reference on this object in the DPE of this second speaker and the definition of a mask translating for this intervening authorizations or prohibitions to execute one or the other method of this object on these data.
    [18]
    A medical information system according to the preceding claims wherein the possible operations defined on the objects can be generic operations such as, but not limited to, sharing, copying (ie creating a new one). object whose data is a copy of the data of the source object), modification, deletion, visualization, printing, or specific operations related to the nature of the data contained by the object, such as a calculation operation , filtering according to specific medical criteria of the subject, expertise or decision support, etc.
    [19]
    19. Medical information system according to the preceding claims wherein the data of the objects are represented according to standards for structuring the medical information, so that the data can reside in an internet cache and thus be accessed in reading or writing. in a secure manner by any active component of the information system referred to herein or by other peripheral systems, such as, but not limited to, a medical imaging platform (106), a support system to the external decision (13,14,15,16), a system for managing and interpreting the results of medical analyzes (6), or the external electronic patient record of an intervener (7), DPE who would dispose of secure connection tools and secure data transport compatible with those of the system considered here.
    [20]
    20. medical information system according to the preceding claim wherein the secure connection mechanisms (11,19) are implementations of security standards of the internet and in particular of single sign-on, such as SAML 2 or OAuth standards 2.0 / UMA.
    [21]
    21. Medical information system according to one of the preceding claims wherein the mechanisms of secure data transport over the Internet (12) are for example provided by the SEDEX data bus implemented by the Swiss federal and cantonal authorities.
    [22]
    22. medical information system according to one of the preceding claims wherein the kernel implemented the concept of information object so that the data of an object can pass between the various components internal and external to the system and that the access control and authorization to execute the methods of this object are implemented strictly in accordance with the information sharing policies defined by the system designers and can be implemented on a case-by-case basis by the responsible parties individual data.
    [23]
    23. Medical information system according to one or more of the preceding claims wherein a web application (102, 108) is made available to the user allowing him to invoke various services by passing them in parameter one or more objects information managed by the system and to which the use is authorized to access.
    [24]
    A medical information system according to the preceding claims wherein the basic services comprise at least, but not limited to, a central patient registry, a central responder registry, a standardized billing service for ambulatory consultation. (21), a standardized coding service for the hospital act, a medical imaging service (20), a medical analysis service (22), an electronic patient record (2), a compendium (13), a drug decision support system (14), internal secure messaging, notification service, secure point-to-point connection service for data transfer between certified systems (12).
    [25]
    25. A medical information system according to the preceding claims wherein the consistency of the information is maintained at all times through the kernel control of the concurrent and distributed execution of the basic services.
    [26]
    26. Medical information system according to the preceding claims wherein web services external to the system can be invoked and to which information objects can be passed in parameter, without the confidentiality of the data is endangered, in particular by implementation of open identity and access management (IAM) standards that federate these services with the medical information system.
    [27]
    Medical information system according to the preceding claims, in which a cache (5) is implemented in the internet for storing and maintaining the data of the information objects and managing the protected accesses to these data according to the protection policies of the data objects. data implemented in the system.
    [28]
    A medical information system according to the preceding claims wherein the kernel implements and maintains the data structures necessary for data management in the internet cache (5) in accordance with data protection policies and object sharing events which have been executed in the course of the life of the system.
    [29]
    29. medical information system according to the preceding claims implemented so that the attending physician intervening in a case always has personal and personal access to an electronic patient record (2) in which he can at any time create, manage, invoke, convey as argument, etc. the objects of information (113,123) which he considers necessary to provide the necessary care and information to his patient according to his good judgment and under his own responsibility.
    类似技术:
    公开号 | 公开日 | 专利标题
    US10930377B2|2021-02-23|Dental health tracking via blockchain
    EP2585964A1|2013-05-01|Interoperability between a plurality of data protection systems
    Mendelson et al.2014|Image sharing: evolving solutions in the age of interoperability
    Kushniruk et al.2008|Human, social, and organizational aspects of health information systems
    Li2017|A service-oriented approach to interoperable and secure personal health record systems
    Al Nuaimi et al.2015|e-Health cloud implementation issues and efforts
    US20200402629A1|2020-12-24|Electronic Healthcare Record Data Blockchain System and Process
    Sunyaev2011|Health-Care Telematics in Germany: Design and Application of a security analysis method
    Kordestani et al.2020|HapiChain: a blockchain-based framework for patient-centric telemedicine
    Kariotis et al.2020|Emerging health data platforms: From individual control to collective data governance
    Lu et al.2006|The architecture of enterprise hospital information system
    Stevovic et al.2013|Compliance aware cross-organization medical record sharing
    Dünnebeil et al.2013|Modular architecture of value-added applications for German healthcare telematics
    CH712507A2|2017-11-30|Method and system for transmitting reserved information, in particular medical information.
    US8931039B2|2015-01-06|Method and system for a document-based knowledge system
    Ciampi et al.2021|Modernizing Healthcare by Using Blockchain
    De la Rosa Algarín et al.2016|Securing XML with role-based access control: Case study in health care
    Kifor et al.2006|Privacy issues of provenance in electronic healthcare record systems
    Rahmouni2011|Ontology based privacy compliance for health data disclosure in Europe
    Bhartiya et al.2013|Exploring interoperability approaches and challenges in healthcare data exchange
    EP1158448A1|2001-11-28|Medical information server
    US20210366585A1|2021-11-25|Treatment adherence systems and processes
    Janchenko et al.2016|INFORMATION SYSTEMS CHALLENGES OF HEALTHCARE IN THE UNITED STATES.
    AU2020298307A1|2022-01-20|Electronic healthcare record data blockchain system
    Genereaux2021|Standards and Interoperability
    同族专利:
    公开号 | 公开日
    CH712507B1|2019-10-15|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    法律状态:
    2017-12-29| PUE| Assignment|Owner name: POOLPRAX AG, CH Free format text: FORMER OWNER: VAUBANTECHNOLOGIES SARL, CH |
    优先权:
    申请号 | 申请日 | 专利标题
    CH6882016|2016-05-30|
    [返回顶部]